Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow multiple signing keys to be provided #4632

Merged

Conversation

stephen-crawford
Copy link
Contributor

@stephen-crawford stephen-crawford commented Aug 9, 2024

Description

[Describe what this change achieves]

  • Category (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)
    This change is an enhancement which allows users to provide multiple signing keys when configuring JWT options.
    Previously, users could only specify a single signing key when configuring their JWT options. As a result, if a user wanted to rotate their key, they would experience some amount of downtime since the cluster would have to reinitialize the update security configuration. This change does not stop the required bouncing, but because you can now provide multiple keys, you can provide backup(s) key(s) which means even when the cluster bounces you have the ability to send JWT requests with the backup key(s).

To specify the multiple keys, you just need to use the same method as before but separate the keys with a comma i.e. <key 1>, <key 2>, etc....

Issues Resolved

[List any issues this PR will resolve]
This PR addresses: #4613

Is this a backport? If so, please add backport PR # and/or commits #, and remove backport-failed label from the original PR.

Do these changes introduce new permission(s) to be displayed in the static dropdown on the front-end? If so, please open a draft PR in the security dashboards plugin and link the draft PR here
No

Testing

[Please provide details of testing done: unit testing, integration testing and manual testing]
I added several new tests to the existing HTTPJWTAuthenticatorTest class.

Check List

  • New functionality includes testing
  • New functionality has been documented
  • New Roles/Permissions have a corresponding security dashboards plugin PR
  • API changes companion pull request created
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Copy link

codecov bot commented Aug 9, 2024

Codecov Report

Attention: Patch coverage is 73.68421% with 10 lines in your changes missing coverage. Please review.

Project coverage is 65.22%. Comparing base (ec9fadb) to head (f5c708f).
Report is 8 commits behind head on main.

Files Patch % Lines
...mazon/dlic/auth/http/jwt/HTTPJwtAuthenticator.java 72.22% 6 Missing and 4 partials ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #4632      +/-   ##
==========================================
- Coverage   65.26%   65.22%   -0.05%     
==========================================
  Files         317      317              
  Lines       22311    22319       +8     
  Branches     3588     3590       +2     
==========================================
- Hits        14562    14558       -4     
- Misses       5954     5964      +10     
- Partials     1795     1797       +2     
Files Coverage Δ
...in/java/org/opensearch/security/util/KeyUtils.java 87.50% <100.00%> (-9.28%) ⬇️
...mazon/dlic/auth/http/jwt/HTTPJwtAuthenticator.java 72.56% <72.22%> (-1.02%) ⬇️

... and 2 files with indirect coverage changes

@derek-ho derek-ho added the backport 2.x backport to 2.x branch label Aug 12, 2024
Signed-off-by: Stephen Crawford <[email protected]>
Signed-off-by: Stephen Crawford <[email protected]>
cwperks
cwperks previously approved these changes Aug 14, 2024
@cwperks
Copy link
Member

cwperks commented Aug 19, 2024

Thanks for creating a documentation issue as well. Do you plan to open a PR along with the issue?

@stephen-crawford stephen-crawford merged commit e2cd610 into opensearch-project:main Aug 20, 2024
41 of 42 checks passed
@opensearch-trigger-bot
Copy link
Contributor

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/security/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/security/backport-2.x
# Create a new branch
git switch --create backport/backport-4632-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 e2cd6101bf2d4f6c4877ec4692ed89be19af2d3b
# Push it to GitHub
git push --set-upstream origin backport/backport-4632-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/security/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-4632-to-2.x.

@cwperks cwperks added the v2.17.0 Issues targeting release v2.17.0 label Aug 20, 2024
stephen-crawford added a commit that referenced this pull request Aug 20, 2024
Copy link
Contributor

@krishna-ggk krishna-ggk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a BWC test to ensure there is no breakage since the type of config is changing from singleton to list?

@cwperks
Copy link
Member

cwperks commented Aug 23, 2024

@krishna-ggk Settings.getAsList is backwards compatible with Settings.get(). The same yaml configuration for jwt can be used with both Settings.get and Settings.getAsList for the signing_key portion of the config:

Example jwt config:

jwt_auth_domain:
    description: "Authenticate via Json Web Token"
    http_enabled: false
    transport_enabled: false
    order: 0
    http_authenticator:
      type: jwt
      challenge: false
      config:
        signing_key: "base64 encoded HMAC key or public RSA/ECDSA pem key"
        jwt_header: "Authorization"
        jwt_url_parameter: null
        roles_key: null
        subject_key: null

One potential issue that could arise would be trying to update the JWT authc config in a mixed cluster of 2.17 and <2.17 nodes.

If the config update hit the 2.17 node and updated the jwt config then the <2.17 nodes would not know how to parse the new config.

Edit:

Settings.getAsList() supports either list entries or comma-separate entries in yaml.

All of these configs work:

signing_key:
  - <signing_key1>
  - <signing_key2>
  - <signing_key3>

signing_key: "<signing_key1>,<signing_key2>,<signing_key3>"

signing_key: "<signing_key1>"

@krishna-ggk
Copy link
Contributor

Thanks @cwperks for clarifying the backward compatibility aspects.

If the config update hit the 2.17 node and updated the jwt config then the <2.17 nodes would not know how to parse the new config.

Does the config update through API generate list or CSV? If so, it could potentially cause issue by generating incompatible version even if only single value is provided. Admittedly though this should be a remote scenario.

Potentially the least riskiest approach would be to introduce a pluralized attribute (signing_keys) which comes at expense of managing deprecation of older attribute. In interest of keeping things simple, I agree current approach is good enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 2.x backport to 2.x branch backport-failed v2.17.0 Issues targeting release v2.17.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants